home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1868.txt < prev    next >
Text File  |  1997-04-01  |  8KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          G. Malkin
  8. Request For Comments: 1868                                Xylogics, Inc.
  9. Category: Experimental                                     November 1995
  10.  
  11.  
  12.                          ARP Extension - UNARP
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an Experimental Protocol for the Internet
  17.    community.  This memo does not specify an Internet standard of any
  18.    kind.  Discussion and suggestions for improvement are requested.
  19.    Distribution of this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    The Address Resolution Protocol allows an IP node to determine the
  24.    hardware (datalink) address of a neighboring node on a broadcast
  25.    network.  The protocol depends on timers to age away old ARP entries.
  26.    This document specifies a trivial modification to the ARP mechanism,
  27.    not the packet format, which allows a node to announce that it is
  28.    leaving the network and that all other nodes should modify their ARP
  29.    tables accordingly.
  30.  
  31. Acknowledgements
  32.  
  33.    Thanks to James Carlson/Xylogics for reviewing this document and
  34.    proposing the backwards compatibility mechanism.
  35.  
  36. 1. Introduction
  37.  
  38.    The primary purpose of the Address Resolution Protocol, as defined in
  39.    [1], is to determine a node's hardware address based on its network
  40.    address (protocol address in ARPspeak).  The ARP protocol
  41.    specifically states that nodes should not periodically advertise
  42.    their existence for two reasons: first, this would generate a lot of
  43.    network traffic and table maintenance overhead; second, it is highly
  44.    unlikely that all nodes will need to communicate to all other nodes.
  45.    Since a node does not advertise its existence, neither does it
  46.    advertise its imminent departure.  This is not a serious problem
  47.    since most ARP implementations maintain timers to age away old
  48.    entries, and departing nodes seldom depart gracefully in any case.
  49.  
  50.    Over time, an additional use has been found for ARP: Proxy ARP.
  51.    While there are those who believe Proxy ARP is an evil thing, it does
  52.    serve a purpose; that is, it allows for communication in ways never
  53.    considered in the original IP architecture.  For example, allows
  54.    dial-in hosts to connect to a network without consuming a large
  55.  
  56.  
  57.  
  58. Malkin                        Experimental                      [Page 1]
  59.  
  60. RFC 1868                         UNARP                     November 1995
  61.  
  62.  
  63.    amount of the IP address space (i.e., all of the hosts contain
  64.    addresses on the same subnet, even though they are not directly
  65.    attached to the physical network associated with that subnet address.
  66.    It is this use of Proxy ARP which produces the problem addressed by
  67.    this document.
  68.  
  69. 2. The Problem
  70.  
  71.    Consider the following topology:
  72.  
  73.                     +--------+
  74.                     | Host A |
  75.                     +--------+
  76.                         |
  77.       ======================================== LAN
  78.           |                             |
  79.       +--------+                    +--------+
  80.       |  CS1   |   comm. servers    |  CS2   |
  81.       +--------+                    +--------+
  82.         |    |                        |    |
  83.        +-+  +-+                      +-+  +-+
  84.        | |  | |       modems         | |  | |
  85.        +-+  +-+                      +-+  +-+
  86.  
  87.    Assume that all of the modems are on the same rotary; that is, when a
  88.    remote host dials in, it may be assigned a modem on either of the
  89.    communication servers.  Further assume that all of the remote hosts'
  90.    IP addresses have the same subnet address as the servers and Host A,
  91.    this in order to conserve address space.
  92.  
  93.    To begin, a remote host dials into CS1 and attempts to communicate
  94.    with Host A.  Host A will assume, based on the subnet mask, that the
  95.    remote host is actually attached to the LAN and will issue an ARP
  96.    Request to determine its hardware address.  Naturally, the remote
  97.    host will not hear this request.  CS1, knowing this, will respond in
  98.    the remote host's place with its own hardware address.  Host A, on
  99.    receiving the ARP Reply, will then communicate with the remote host,
  100.    transparently through CS1.  So far everything is just fine.
  101.  
  102.    Now, the remote host disconnects and, before Host A can age its ARP
  103.    cache, reconnects through CS2.  Herein lies the problem.  Whenever
  104.    Host A attempts to send a packet to the remote host, it will send it
  105.    to CS1 because it cannot know that its ARP cache entry is invalid.
  106.    If, when the remote host disconnects, the server to which it was
  107.    attached could inform other nodes on the LAN that the protocol
  108.    address/hardware address mapping was no longer valid, the problem
  109.    would not occur.
  110.  
  111.  
  112.  
  113.  
  114. Malkin                        Experimental                      [Page 2]
  115.  
  116. RFC 1868                         UNARP                     November 1995
  117.  
  118.  
  119. 3. The Solution
  120.  
  121.    When a server, as described above, disconnects from a remote host for
  122.    which it has responded to a Proxy ARP, it broadcasts an UNARP.  An
  123.    UNARP is an unsolicited ARP Reply with the following field values:
  124.  
  125.       Hardware Address Space       as appropriate
  126.       Protocol Address Space       0x800 (IP)
  127.       Hardware Address Length      0 (see Backwards Compatibility)
  128.       Protocol Address Length      4 (length of an IP address)
  129.       Opcode                       2 (Reply)
  130.       Source Hardware Address      Not Included
  131.       Source Protocol Address      IP address of detaching host
  132.       Target Hardware Address      Not Included
  133.       Target Protocol Address      255.255.255.255 (IP broadcast)
  134.  
  135.       NOTE: this is a 16-byte packet (not including MAC header)
  136.  
  137.    On receiving an UNARP, a node deletes the ARP cache entry associated
  138.    with the IP address.
  139.  
  140.    It is not strictly necessary that a server keep state information
  141.    about whether or not it has actually sent a Proxy ARP Reply; it would
  142.    be sufficient if a server always sends an UNARP when a remote host
  143.    disconnects.
  144.  
  145.    Of course, there is no reason why a host which gracefully detaches
  146.    from a LAN cannot also send an UNARP for itself.  This would be
  147.    especially useful if, upon re-attaching, it might have a different
  148.    hardware address.
  149.  
  150. 4. Backwards Compatibility
  151.  
  152.    The modifications to support UNARP are trivial, so there is every
  153.    expectation that it will be widely supported.  Of course, there will
  154.    be a period of time during which nodes which support UNARP will
  155.    coexist with nodes which do not support UNARP.  To prevent
  156.    unenlightened nodes from adding spurious ARP cache entries with
  157.    hardware addresses of zero, UNARP packets specify a hardware address
  158.    length of zero.  This should be rejected by nodes which do not
  159.    support UNARP.  As a consequence of this, the source and target
  160.    hardware address fields do not exist in UNARP packets (as previously
  161.    described).
  162.  
  163.    It is recommended that implementors include a configuration switch to
  164.    disable UNARP in the event that some vendor's ARP implementation
  165.    might take offense at the abbreviated UNARP packet format.
  166.  
  167.  
  168.  
  169.  
  170. Malkin                        Experimental                      [Page 3]
  171.  
  172. RFC 1868                         UNARP                     November 1995
  173.  
  174.  
  175. 5. Security Considerations
  176.  
  177.    Security issues are not discussed in this memo.
  178.  
  179. References
  180.  
  181.    [1] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37,
  182.        RFC 826, MIT, November 1982.
  183.  
  184. Author's Address
  185.  
  186.    Gary Scott Malkin
  187.    Xylogics, Inc.
  188.    53 Third Avenue
  189.    Burlington, MA  01803
  190.  
  191.    Phone:  (617) 272-8140
  192.    EMail:  gmalkin@xylogics.com
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Malkin                        Experimental                      [Page 4]
  227.  
  228.